For commercial applications, a client computing platform typically operates in an environment where its behaviour is vulnerable to modification by local or remote entities. This potential insecurity of the platform is a limitation on its use by local parties who might otherwise be willing to use the platform, or remote parties who might otherwise communicate with the platform; for example, for the purposes of E-commerce.
In the applicant's co-pending disclosure WO 00/48063, incorporated herein by reference, there is disclosed the concept of a ‘trusted computing platform’ comprising a computing platform which has a ‘trusted component’ in the form of a built-in hardware and software component. This document describes the use of a Trusted Device (TD) or Trusted Platform Module (TPM) to enable verification of the integrity of computing apparatus by the reliable measurement and reporting of integrity metrics. A TD/TPM conforms to the Trusted Computing Platform Alliance (TCPA) specification, see for example www.trustedpc.org.
A Trusted Device or Trusted Platform Module may include one or more logically protected computing environments or “compartments” within which a service or process may be run. The actions or privileges within a compartment are constrained, particularly to restrict the ability of a process to execute methods and operations which have effect outside the compartment, such as methods that request network access or access to files outside of the compartment. Also, operation of a process or service within a compartment is performed with a high level of isolation from interference and prying by outside influences. The or each compartment may be an operating system compartment controlled by an operating system kernel. This is also referred to as a compartmented operating system or a trusted operating system.
Trusted operating systems have been available for several years in a form designed for handling and processing classified (military) information, using a containment mechanism enforced by a kernel of the operating system with mandatory access controls to resources of the computing platform such as files, processes and network connections. The operating system attaches labels to the resources and enforces a security policy which governs the allowed interaction between these resources based on their label values. Many trusted operating systems apply a security policy based on the Bell-Lapadula model discussed in the paper “Applying Military Grade Security to the Internet” by C I Dalton and J F Griffin published in Computer Networks and ISDN Systems 29 (1997) 1799-1808.
In any event, many trusted computing platforms adopt a relatively simple and convenient form of operating system compartment. As a general rule, each resource of the computing platform which it is desired to protect is given a label indicating the compartment to which that resource belongs. Mandatory access controls, incorporating a security policy, are performed by the kernel of the host operating system to ensure that resources from one compartment cannot interfere with resources from another compartment. In a secure system, access to system resources is defined by security or subject attributes.
The above-mentioned security policy tends to be expressed in the form of security rules (each generally comprising an instruction line defining security attributes). In general, one or more security rules are associated with a compartment, and each compartment may be associated with one or more services. File rules may be used to define mandatory access controls in addition to the usual discretionary access control. In general, a file rule has a comp field defining which compartment the rule applies to, and a filename field defining the directory or file the rule applies to. File rules on a directory apply to the directory and all files reachable from the directory. The access permitted by a file rule is defined by its access field.
The forms of access, in one known system, are read, write, append, execute. For most file operations, the operation is only permitted if the access requested by the operation is granted by the applicable file rules, or there are no applying file rules.
Consider the case where a website under /compt/web is running in compartment web. To prevent the website being defaced, a read-only rule may be put on /compt/web:                file [comp web; filename /comp/web; access read;]        
However, the webserver may need to write logs, so read-write access may be given to /compt/web/logs:                file [comp web; filename /comp/web/logs; access read, write]        
The intention is that a file rule defines the maximum permission of files reachable from its filename. In some conventional systems, where a file is reachable from the filename in more than one rule, the “most specific” rule is used, i.e. the one with the longest filename. If there is no rule applying to a file, its permissions are not constrained, and the usual permissions specified on the file control operations on it. Rules for different compartments tend to be treated independently.
However, this definition of the behaviour has been found to be inadequate. In some known systems, the filesystem maps filenames onto the files themselves, which are identified uniquely by device number and inode number. Many filnames can resolve to the same file because of the presence of hard links, symbolic links, multiple mounts and mounts using —bind to mount one directory on another. This may be called ‘filename aliasing’, and it means that it is not always clear when more than one rule applies to a file, or indeed if any rule applies to a file. In addition, there is also the problem of rule conflict, in the sense that filename aliasing means that two rules with different filenames can have some files to which only one rule applies, and some files to which both rules potentially apply.
Referring to FIG. 3 of the drawings, consider the following file rule r1:                file [comp web; filename /x; access read;]        
Thus, if a user were to try and write to a file /x/f from compartment web, it will fail with operation not permitted (because directory x has read-only access defined by r1, which also applies to /x/f). However, consider the case that another directory /y also exists, to which rule r2 applies:                file [comp web; filename /y; access read, write]        
A user could create a hard link to /x/f called /y/f because they have write access to /y and only need read access to /x/f to create the link. Thus, if filename /y/f is accessed, this will resolve to the same inode 100 as /x/f but the kernel dentry will show /y as the parent and will apply r2 even though r1 should be applied, without knowing that /y/f is an alias for a file /x/f. On the other hand, if /y/f were a symbolic link to /x/f, the kernel dentry for the inode 100 has /x as the parent and r1 would be correctly applied.
On the other hand, referring to FIG. 4 of the drawings, suppose a symbolic link /x/y is provided to /y. Then the filename /x/y/f resolves to the same file inode 100 as y/f, so on the face of it r1 should apply to /x/y/f. However, the kernel would resolve /x/y/f to a dentry for /y/f, since /x/y is a symbolic link.
File aliases can also be produced by mounting the same filesystem on more than one directory. Although hard-linking to a directory can be prevented, a similar effect can be produced in one known system using a ‘mount-bind’ command which allows a directory to be mounted on any other directory, effectively linking the mount point to the directory mounted.
Websites can be defaced by attackers using buffer overflow bugs in the webserver to get it to run their code and write to the website files. The exemplary website rules given above are intended to prevent this, even if the webserver has a buffer overflow bug. However, they do not effectively achieve this in all cases, unless the issue of filename aliasing is resolved. Otherwise, an attacker can cause the webserver to create a hard link in /compt/web/logs (which has read-write access) to file under/compt/web (which only has read access). The attacker can then access the file via the hard link, by-passing the read-only protection, so the rules do not necessarily prevent the website being defaced, unless the issue of filename aliasing is resolved.
Furthermore, in some known systems, a security policy is used which classifies files into types and then defines the access permitted on the basis of the types. Classification is done as a separate phase and the results are stored. Files are not reclassified when they are renamed, or when links to them are created, and the classification process must instead be run manually when the policy is changed. This is clearly inconvenient and time-consuming, not to mention complicated and prone to error.